home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0055-Changing MacApp sou-Oct89 < prev    next >
Encoding:
Text File  |  1989-10-12  |  2.6 KB  |  61 lines  |  [TEXT/GEOL]
  1. Item    8981286                         12-Oct-89        08:06
  2.  
  3. From:   D2086                           Efficient Field Svc, C Faith,PRT
  4.  
  5. To:     MUYSVASOVIC1                    ER&D - J-D Muys-Vasovic
  6.         MACAPP.TECH$                    MACAPP Tech
  7.  
  8. Sub:    Changing MacApp source again!
  9.  
  10. Jean-Denis,
  11.  
  12. Actually I think the problem of changing source code is very much related to
  13. MacApp (or any similar published class library), although it can be solved by
  14. certain potential constructs in the language it is not primarily a language
  15. issue.
  16.  
  17. MacApp is a uniform set of objects that we are hesitant to change because they
  18. are not ours.  We neither own them nor control what changes in them on an
  19. official basis.  This means that as the official version of MacApp changes we
  20. change our versions to more closely match that version.
  21.  
  22. Without MacApp's presence, if we were dealing entirely with our own source, we
  23. would simply change the source and that would become the next version, there
  24. would be no downside to making changes (unless we had shipped applications
  25. based on previous versions of our own code).
  26.  
  27. I think there should be an official way to make changes in MacApp (or at least
  28. what gets linked into our program).
  29.  
  30. I suggest 2 things (yes I have suggested them before):
  31.  
  32. We use a new Keyword REPLACE to specify methods that are not OVERRIDE's but
  33. that actually replace the definitions in a class, for example one could specify
  34. a method that would REPLACE TView.IRes.  This replacement would affect all
  35. descendants of TView in the normal fashion.  The word REPLACE would tell the
  36. linker, "this is the definition to use" (not the one in MacApp) and would avoid
  37. the ambiguities of multiply defined symbols.  REPLACE would be useful when one
  38. wanted to change one or two implementations of certain methods.
  39.  
  40. We should also have an ALIAS keyword, this would allow us to add functionality
  41. to the class hierarchy.  As an example, suppose we wanted to be able to have
  42. all TEvtHandlers respond to certain System 7 IAC events.  We could define a new
  43. OBJECT TIACEvtHandler = OBJECT(TEvtHandler)
  44.  
  45.    FUNCTION TIACEvtHandler.DoIACMessage(theMessage: Message): TCommand;
  46.  
  47. END;
  48.   and then define:
  49. ALIAS TEvtHandler = TIACEvtHandler
  50.  
  51. This would have the effect of making all descendants of TEvtHandler really
  52. descendants of TIACEvtHandler, in effect adding functionality to TEvtHandler at
  53. link time.
  54.  
  55. Perhaps I am not looking at things properly but I would find this sort of
  56. capability extremely useful.  It would enable a lot of really interesting sort
  57. of changes that would otherwise be really ugly to implement.
  58.  
  59. - Curtis
  60.  
  61.